Service composition can be categorized into a static service composition and a dynamic service composition. For the static service composition, the composite service logic specifies in advance a concrete service to be invoked. That is, the service to be invoked is specified before the composite service logic is being executed. For instance, the composite service logic may be generated via a graphic user interface or text editor. Some service composition environment provides a graphic user interface, allowing users to be able to use a mouse to drag appropriate services from a service catalog to build up the composite service logic. Such mechanism may not be able to dynamically select and provide appropriate services to a requester in the runtime. Such mechanism has serious defects especially when the service is inaccessible.
For the dynamic service composition, the composite service logic specifies a service to be invoked in runtime such that some defects of the static service composition are addressed. Currently, dynamic service composition is mainly based on semantic technology. The dynamic service composition can be categorized into a semi-auto composition and auto composition. The semi-auto composition is directed to providing semantic service description when a user is defining a composite service logic. The user still needs to describe in advance the execution sequence of the services to be invoked. However, the auto composition only requires some necessary parameters before automatically generating the composite service logic, which means that the sequence for the services to be invoked is generated automatically and appropriate services are selected automatically. Generally, techniques such as Artificial Intelligence planning (AI planning) are used to automatically select services and generate the composite service logic.
Currently, the existing technique provides an implementation mechanism for converting an abstract composite service logic to a concrete composite service logic.
First, different stages for service composition are defined, namely, design stage, service selection stage, procedure generation stage and execution stage. A template of a semantic activity is used for designing a service composition procedure. Then, a service is dynamically selected for each activity. This step is repeated until each activity is replaced with a concrete service. Again, an executable procedure is generated based on all the concrete services. Finally, the executable composite service logic is executed.
Specifically, a process for using Ontology Web Language for Service (OWL-S) to replace activity with concrete service is described below. OWL-S is used to describe an activity. Semantic description is used to match a concrete service. Business Process Execution Language (BPEL) Script is then generated. The main feature is to employ OWL-S to describe service invocation. A service composition engine traverses the composite service logic. When the engine encounters the service invocation described in OWL-S, an “abstract-to-concrete” procedure is triggered. The service composition engine discovers a concrete service by virtue of OWL-S service description dynamically. The composite engine replaces the OWL-S service invocation description with an invocation description of the concrete service. BPEL script is generated until all the OWL-S service invocation descriptions are replaced.
Therefore, as can be seen, the foregoing process requires people to provide semantic description and the implementation is complex. Moreover, the foregoing process indirectly converts the abstract composite service logic into a concrete composite service logic, rather than directly executing the abstract composite service logic. Likewise, in the prior art, no mechanism of converting a concrete composite service logic into an abstract composite service logic is disclosed. Moreover, prior art does not solve the issue raised when the invoked service is not accessible during an execution process of a composite service logic.